Is It Safe to Uplift This Patch? An Empirical Study on Mozilla Firefox

In rapid release development processes, patches that fix critical issues, or implement high-value features are often promoted directly from the development channel to a stabilization channel, potentially skipping one or more stabilization channels. This practice is called patch uplift. Patch uplift is risky, because patches that are rushed through the stabilization phase can end up introducing regressions in the code. This paper examines patch uplift operations at Mozilla, with the aim to identify the characteristics of uplifted patches that introduce regressions. Through statistical and manual analyses, we quantitatively and qualitatively investigate the reasons behind patch uplift decisions and the characteristics of uplifted patches that introduced regressions. Additionally, we interviewed three Mozilla release managers to understand organizational factors that affect patch uplift decisions and outcomes. Results show that most patches are uplifted because of a wrong functionality or a crash. Uplifted patches that lead to faults tend to have larger patch size, and most of the faults are due to semantic or memory errors in the patches. Also, release managers are more inclined to accept patch uplift requests that concern certain specific components, and-or that are submitted by certain specific developers.Comment: In proceedings of the 33rd International Conference on Software Maintenance and Evolution (ICSME 2017

Improving software engineering processes using machine learning and data mining techniques

The availability of large amounts of data from software development has created an area of research called mining software repositories. Researchers mine data from software repositories both to improve understanding of software development and evolution, and to empirically validate novel ideas and techniques. The large amount of data collected from software processes can then be leveraged for machine learning applications. Indeed, machine learning can have a large impact in software engineering, just like it has had in other fields, supporting developers, and other actors involved in the software development process, in automating or improving parts of their work. The automation can not only make some phases of the development process less tedious or cheaper, but also more efficient and less prone to errors. Moreover, employing machine learning can reduce the complexity of difficult problems, enabling engineers to focus on more interesting problems rather than the basics of development. The aim of this dissertation is to show how the development and the use of machine learning and data mining techniques can support several software engineering phases, ranging from crash handling, to code review, to patch uplifting, to software ecosystem management. To validate our thesis we conducted several studies tackling different problems in an industrial open-source context, focusing on the case of Mozilla

Understanding flaky tests: the developer’s perspective

Flaky tests are software tests that exhibit a seemingly random outcome (pass or fail) despite exercising unchanged code. In this work, we examine the perceptions of software developers about the nature, relevance, and challenges of flaky tests. We asked 21 professional developers to classify 200 flaky tests they previously fixed, in terms of the nature and the origin of the flakiness, as well as of the fixing effort. We also examined developers' fixing strategies. Subsequently, we conducted an online survey with 121 developers with a median industrial programming experience of five years. Our research shows that: The flakiness is due to several different causes, four of which have never been reported before, despite being the most costly to fix; flakiness is perceived as significant by the vast majority of developers, regardless of their team's size and project's domain, and it can have effects on resource allocation, scheduling, and the perceived reliability of the test suite; and the challenges developers report to face regard mostly the reproduction of the flaky behavior and the identification of the cause for the flakiness. Public preprint [http://arxiv.org/abs/1907.01466], data and materials [https://doi.org/10.5281/zenodo.3265785]

Standardization of Road Danger Signs in the European Union

The aim of this research is to find a solution for the standardization of road signs in the EU zone by a comparative analysis of different national sign systems to establish a common set from a single country. This work is based on the idea that road sign standardization might increase the safety level of transnational journeys and foster the relationships among the various members of the EU Community. This paper presents the outcome of the first step of the research, which focuses on the harmonization of danger signs. In more detail, a multicriteria approach is applied to rank 19 EU Member States on the basis of three main aspects: the installation cost of new signs, new sign learning issues and the effectiveness of sign systems. The study allows for the installation cost by quantifying the degree of similarity among road sign systems and the roadway network extension, on which new signs should be placed.</span

rust-code-analysis: A Rust library to analyze and extract maintainability information from source codes

The literature proposes many software metrics for evaluating the source code non-functional properties, such as its complexity and maintainability. The literature also proposes several tools to compute those properties on source codes developed with many different software languages. However, the Rust language emergence has not been paired by the community’s effort in developing parsers and tools able to compute metrics for the Rust source code. Also, metrics tools often fall short in providing immediate means of comparing maintainability metrics between different algorithms or coding languages. We hence introduce rust-code-analysis, a Rust library that allows the extraction of a set of eleven maintainability metrics for ten different languages, including Rust. rust-code-analysis, through the Abstract Syntax Tree (AST) of a source file, allows the inspection of the code structure, analyzing source code metrics at different levels of granularity, and finding code syntax errors before compiling time. The tool also offers a command-line interface that allows exporting the results in different formats. The possibility of analyzing source codes written in different programming languages enables simple and systematic comparisons between the metrics produced from different empirical and large-scale analysis sources

Effect of meteorological and agronomic factors on maize grain contamination by fumonisin

Fumonisins are toxic secondary metabolites produced by fungi such as F.verticilloides. Maize is commonly colonized by several spoilage fungi both in pre- and post-harvest conditions. Field infection prevention is the best solution to contain contamination, using practices aimed at restricting plant stress and limiting the propagation of the disease. This work is focused on understanding the effect of environmental factors on the production of fumonisins in Friuli Venezia Giulia (NE Italy) on maize crops. The analysis has been performed on a dataset covering a period of 14 years (from 2000 to 2013), recording fumonisins contamination and daily meteorological data (air temperature, RH, Rain, Wind speed) for 13 different drying plants and for three different harvest times (early, medium and late). The drying plants collect grain production from an area of about 70.000-100.000 ha. Data were analyzed by full factorial ANOVA and a multiple regression approach was performed using STATA and SEMoLa software. ANOVA test pointed out a significant effect of factors \u201cyear\u201d and \u201charvest time\u201d (p<0.01) for fumonisin content. Instead, location had no significant effect. The best regression model (R2=0. 65, 2... observation) detected a significant correlation between fumonisin concentration and meteorological data in the period from 15th to 31st July. High fumonisin contents were positively correlated with daily thermal excursion, minimum temperature and wet conditions in this period. Silk drying and harvest time resulted as the key factors to contain and study fumonisins contamination in maize. Results will be used to implement a more complex dynamic model

SZZ in the time of Pull Requests

In the multi-commit development model, programmers complete tasks (e.g., implementing a feature) by organizing their work in several commits and packaging them into a commit-set. Analyzing data from developers using this model can be useful to tackle challenging developers' needs, such as knowing which features introduce a bug as well as assessing the risk of integrating certain features in a release. However, to do so one first needs to identify fix-inducing commit-sets. For such an identification, the SZZ algorithm is the most natural candidate, but its performance has not been evaluated in the multi-commit context yet. In this study, we conduct an in-depth investigation on the reliability and performance of SZZ in the multi-commit model. To obtain a reliable ground truth, we consider an already existing SZZ dataset and adapt it to the multi-commit context. Moreover, we devise a second dataset that is more extensive and directly created by developers as well as Quality Assurance (QA) engineers of Mozilla. Based on these datasets, we (1) test the performance of B-SZZ and its non-language-specific SZZ variations in the context of the multi-commit model, (2) investigate the reasons behind their specific behavior, and (3) analyze the impact of non-relevant commits in a commit-set and automatically detect them before using SZZ

Cross section measurements of 155,157Gd(n, γ) induced by thermal and epithermal neutrons

© SIF, Springer-Verlag GmbH Germany, part of Springer Nature 2019Neutron capture cross section measurements on 155Gd and 157Gd were performed using the time-of-flight technique at the n_TOF facility at CERN on isotopically enriched samples. The measurements were carried out in the n_TOF experimental area EAR1, at 185 m from the neutron source, with an array of 4 C6D6 liquid scintillation detectors. At a neutron kinetic energy of 0.0253 eV, capture cross sections of 62.2(2.2) and 239.8(8.4) kilobarn have been derived for 155Gd and 157Gd, respectively, with up to 6% deviation relative to values presently reported in nuclear data libraries, but consistent with those values within 1.6 standard deviations. A resonance shape analysis has been performed in the resolved resonance region up to 181 eV and 307 eV, respectively for 155Gd and 157Gd, where on average, resonance parameters have been found in good agreement with evaluations. Above these energies and up to 1 keV, the observed resonance-like structure of the cross section has been analysed and characterised. From a statistical analysis of the observed neutron resonances we deduced: neutron strength function of 2. 01 (28) × 10 - 4 and 2. 17 (41) × 10 - 4; average total radiative width of 106.8(14) meV and 101.1(20) meV and s-wave resonance spacing 1.6(2) eV and 4.8(5) eV for n + 155Gd and n + 157Gd systems, respectively.Peer reviewedFinal Accepted Versio

The 33S(n,α)30Si cross section measurement at n-TOF-EAR2 (CERN) : From 0.01 eV to the resonance region

The 33S(n,α)30Si cross section measurement, using 10B(n,α) as reference, at the n-TOF Experimental Area 2 (EAR2) facility at CERN is presented. Data from 0.01 eV to 100 keV are provided and, for the first time, the cross section is measured in the range from 0.01 eV to 10 keV. These data may be used for a future evaluation of the cross section because present evaluations exhibit large discrepancies. The 33S(n,α)30Si reaction is of interest in medical physics because of its possible use as a cooperative target to boron in Neutron Capture Therapy (NCT)